home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12844 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.7 KB
  1. Path: scoop.eco.twg.com!usenet
  2. From: mike@vishnu.eco.twg.com (This space intentionally left blank)
  3. Newsgroups: comp.lang.c++,comp.programming
  4. Subject: Re: Young programmers read me.
  5. Date: 21 Mar 1996 23:50:33 GMT
  6. Organization: The Wollongong Group
  7. Message-ID: <4isq0a$5gr@scoop.eco.twg.com>
  8. References: <4icpp9$7hr@barad-dur.nas.com> <4imqe4$cj3@ping1.ping.be>
  9.     <4ippuq$4pk@scoop.eco.twg.com> <4iq5rv$aph@aadt>
  10. NNTP-Posting-Host: vishnu.eco.twg.com
  11.  
  12. In article <4iq5rv$aph@aadt>, david_hooker@sdt.com writes:
  13. >In <4ippuq$4pk@scoop.eco.twg.com>, mike@vishnu.eco.twg.com (This space intentionally left blank) writes:
  14. >
  15. >>Sure, it's less flamboyant and "macho" to just engineer good software, code
  16. >>it and have it work and be simple to maintain, but the old days of "it was
  17. >>hard to write, it should be hard to modify" and 18-24 hour "crunch" days at
  18. >>the end of the project when you have "just one more bug...or maybe two..."
  19. >>need to be over.  Customers don't like having to use support lines to get
  20. >>problems fixed any more than companies like to pay to provide them.
  21. >
  22. >Actually, around here the "macho" programmers are those that do it right the
  23. >_first_ time!!  Our "falmboyant" programmers get complex pieces of code
  24. >done _right_, and get it done _on_time_ or even (drumroll...) early!!
  25.  
  26. Good for you.  This does not appear to be the norm in the industry.  Why not?
  27.  
  28. >Someone who needs a buttload of time to write something is either a beginner,
  29. >an amateur, or a below-average performer --- definately not "macho".  And we
  30. >use C++ (our system has 700,000 - 1,000,000 LOC).
  31.  
  32. Or is working on a less-than well-defined problem, or is trying to hit a
  33. moving target, or was lied to about the environment, or was given a target
  34. date half as far in the future as the best estimate of the time required, or
  35. didn't get the resources the estimate was based on, or a host of other
  36. things I've seen repeatedly at a number of different companies.
  37.  
  38. This sounds a lot like the "macho" attitude I mentioned.  "*We* can put out
  39. buku piles of code with anything!  Who needs tools that help?!?  Sissies!!"
  40.  
  41. >>If you don't agree, check out any of the Corel newsgroups and see how thier
  42. >>customers feel about the seemingly endless bugs in their products.  Sure, they
  43. >>fix them...eventually (I was up to CorelDRAW 5.0 rev F before things started
  44. >>working properly)...but how many hundreds of thousands of lost production hours
  45. >>are created by pointer bugs, memory leaks, unintended type conversions, array
  46. >>out of bounds errors, and other types of errors made simple by C/C++ and less
  47. >>easy to generate by other languages, such as Ada?  Corel has said publicly that
  48. >>it isn't possible to write bug-free code in a comptitive marketplace using C or
  49. >>C++...it just takes too much time in those languages and they'd likely miss
  50. >>something anyway, so they don't bother and just let the customers locate those
  51. >>bugs that really bother them.
  52. >
  53. >Sound's like a either bad programmers, or just a bad attitude.
  54.  
  55. Or an unreasonable/shortsighted management, or a flakey environment (MS Windows
  56. 3.1) combined with a language that makes it easy to code errors, and even
  57. encourages poor practices.
  58.  
  59. >Writing well-engineered software in C++ (probably) does take more dicipline
  60. >than several other languages.  And I personally would prefer a well-
  61. >diciplined programmer (in any language) over one that's not.  
  62.  
  63. I can't argue with this at all.
  64.  
  65. >In my opinion,
  66. >it's the programmer, not the language, that makes or breaks the code.
  67.  
  68. Yes, but the ease with which a programer of any skill level can acomplish a
  69. given task is dependent on the tools used.  The better the tools the better
  70. the result for a given programmer (better programmers will still beat poorer
  71. programmers on speed, quality, maintainability, etc.).  Michaelangelo did
  72. wonderous things with a wooden mallet and some primitive steel chisels. 
  73. Just think what his output could have been with an air compressor, airhammer
  74. and some modern steel tools!  Less time and attention spent aiming and
  75. swinging the mallet and more time spent thinking about where and what to cut...
  76.  
  77. -- Mike "his results may have looked the same, but we'd have a lot more of 
  78.          them to look at" Bartman --
  79.  
  80. ==============================================================================
  81. | I didn't really say all the things that I said.  You probably didn't read  |
  82. | what you thought you read.  Statistics show that this whole thing is more  |
  83. | than likely just a hideous misunderstanding.                     |
  84. ==============================================================================
  85.  
  86. ==============================================================================
  87. Praise the lord and pass the ammunition.
  88. ------------------------------------------------------------------------------
  89.  
  90.